set

* Enforce the `-Zregparm=N` flag by setting the NumRegisterParameters
LLVM module flag * Add assembly tests verifying that the parameters are
passed in registers for reparm values 1, 2, and 3, for both LLVM
intrinsics and non-builtin functions * Add c_void type to minicore

This handles various kinds of errors, but does not allow applying the
derive yet.

This adds the feature gate `macro_derive`.

Add infrastructure to apply a derive macro to arguments, consuming and
returning a `TokenTree` only.

Handle `SyntaxExtensionKind::MacroRules` when expanding a derive, if the
macro's kinds support derive.

Add tests covering various cases of `macro_rules` derives.

Note that due to a pre-existing FIXME in `expand.rs`, derives are
re-queued and some errors get emitted twice. Duplicate diagnostic
suppression makes them not visible, but the FIXME should still get
fixed.

"privalage" -> "privilege"

Fix outdated doc comment

This updates the documentation comment for `Type::is_doc_subtype_of` to more accurately describe its purpose as a subtyping check, rather than equality

fixes rust-lang#138572

r? `@tgross35`

…enkov

Implement declarative (`macro_rules!`) derive macros (RFC 3698)

This is a draft for review, and should not be merged yet.

This is layered atop rust-lang#145153 , and has
only two additional commits atop that. The first handles parsing and provides a
test for various parse errors. The second implements expansion and handles
application.

This implements RFC 3698, "Declarative (`macro_rules!`) derive macros".
Tracking issue: rust-lang#143549

This has one remaining issue, which I could use some help debugging: in
`tests/ui/macros/macro-rules-derive-error.rs`, the diagnostics for
`derive(fn_only)` (for a `fn_only` with no `derive` rules) and
`derive(ForwardReferencedDerive)` both get emitted twice, as a duplicate
diagnostic.

From what I can tell via adding some debugging code,
`unresolved_macro_suggestions` is getting called twice from
`finalize_macro_resolutions` for each of them, because
`self.single_segment_macro_resolutions` has two entries for the macro, with two
different `parent_scope` values. I'm not clear on why that happened; it doesn't
happen with the equivalent code using attrs.

I'd welcome any suggestions for fixing this.

…ross35

Fix `-Zregparm` for LLVM builtins

This fixes the issue where `-Zregparm=N` was not working correctly when calling LLVM intrinsics

By default on `x86-32`, arguments are passed on the stack. The `-Zregparm=N` flag allows the first `N` arguments to be passed in registers instead.

When calling intrinsics like `memset`, LLVM still passes parameters on the stack, which prevents optimizations like tail calls.

As proposed by `@tgross35,` I fixed this by setting the `NumRegisterParameters` LLVM module flag to `N` when the `-Zregparm=N` is set.

```rust
// compiler/rust_codegen_llvm/src/context.rs#375-382
if let Some(regparm_count) = sess.opts.unstable_opts.regparm {
    llvm::add_module_flag_u32(
        llmod,
        llvm::ModuleFlagMergeBehavior::Error,
        "NumRegisterParameters",
        regparm_count,
    );
}
```
[Here](https://rust.godbolt.org/z/YMezreo48) is a before/after compiler explorer.

Here is the final result for the code snippet in the original issue:
```asm
entrypoint:
        push    esi
        mov     esi, eax
        mov     eax, ecx
        mov     ecx, esi
        pop     esi
        jmp     memset   ; Tail call parameters in registers
```

Fixes: rust-lang#145271

Add codegen test for issue 122734

Closes rust-lang#122734

Fix typo in doc for library/std/src/fs.rs#set_permissions

"privalage" -> "privilege".

Was reading the docs and have noticed this.